<html>
<head><meta charset="utf-8"><title>Supported ABIs · t-compiler · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/index.html">t-compiler</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html">Supported ABIs</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="229583892"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229583892" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> isHavvy <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229583892">(Mar 10 2021 at 00:54)</a>:</h4>
<p>In <a href="https://github.com/rust-lang/reference/issues/975">https://github.com/rust-lang/reference/issues/975</a> it is noted that we don't document which ABIs are supported by the compiler in the rustc book nor in the reference. As far as I'm aware, the supported ABIs is a compiler decision, not a language decision, so should we be documenting them in the rustc book?</p>
<p>Also, I assume some of them should be defined in all Rust implementations, but I'm not sure which ones those would be.</p>



<a name="229591493"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229591493" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229591493">(Mar 10 2021 at 02:22)</a>:</h4>
<p>To clarify, the ABIs are documented at <a href="https://doc.rust-lang.org/nightly/reference/items/external-blocks.html#abi">https://doc.rust-lang.org/nightly/reference/items/external-blocks.html#abi</a></p>
<blockquote>
<p>the supported ABIs is a compiler decision, not a language decision</p>
</blockquote>
<p>Can you say more why you think that should be?  I can only think of lint names as a language-exposed concept that are marked as compiler-specific.  I think there is value in avoiding compiler-specific things as much as possible.</p>



<a name="229594235"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229594235" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> isHavvy <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229594235">(Mar 10 2021 at 02:55)</a>:</h4>
<p>As in, if there is a second Rust compiler, it should not have to support every single ABI that rustc does. Although without a second compiler, it's all theoretical.</p>



<a name="229597162"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229597162" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229597162">(Mar 10 2021 at 03:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="296643">isHavvy</span> <a href="#narrow/stream/131828-t-compiler/topic/Supported.20ABIs/near/229594235">said</a>:</p>
<blockquote>
<p>As in, if there is a second Rust compiler, it should not have to support every single ABI that rustc does. Although without a second compiler, it's all theoretical.</p>
</blockquote>
<p>Indeed.<br>
Though even on rustc, it's already implementation-specific, if you consider the different platforms to be distinct "implementations".  <code>extern"fastcall"</code> makes little sense on x86_64-pc-linux-gnu, after all, and rustc does reflect this.</p>



<a name="229597390"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229597390" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229597390">(Mar 10 2021 at 03:37)</a>:</h4>
<p>There is also distinctions between rustc and rustc-with-<code>feature(unboxed_closures)</code> in that the latter also supports <code>extern"rust-call"</code> on function definitions.</p>



<a name="229597409"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229597409" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229597409">(Mar 10 2021 at 03:37)</a>:</h4>
<p>Why not, though?  What's special about ABIs that they shouldn't be stabilized in the language? I think it is desirable to maximize how much Rust code works on all Rust compilers.</p>
<p>(I would say that an implementation that doesn't support a particular target doesn't need to support ABIs specific to that target.)</p>
<p>If there are implementation-defined extensions, I think it would be good for there to be some way to distinguish those.  I personally wouldn't be comfortable saying the ABI string is a free-for-all unregulated namespace.</p>



<a name="229597716"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229597716" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229597716">(Mar 10 2021 at 03:40)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120518">Eric Huss</span> <a href="#narrow/stream/131828-t-compiler/topic/Supported.20ABIs/near/229597409">said</a>:</p>
<blockquote>
<p>Why not, though?  What's special about ABIs that they shouldn't be stabilized in the language? I think it is desirable to maximize how much Rust code works on all Rust compilers.</p>
<p>(I would say that an implementation that doesn't support a particular target doesn't need to support ABIs specific to that target.)</p>
<p>If there are implementation-defined extensions, I think it would be good for there to be some way to distinguish those.  I personally wouldn't be comfortable saying the ABI string is a free-for-all unregulated namespace.</p>
</blockquote>
<p>What if an implementation wants to provide aditional abis, such as linking to or defining C++ functions with properly mangled names?  Or allowing FFI to swift, because it also supports compiling and linking swift? <br>
Also, the abi string already is an unregulated namespace. There are 3 rustc unstable features that define compiler-specific extension abis, the abis being <code>"rust-call"</code>, <code>"rust-intrinsic"</code>, and <code>"platform-intrinsic"</code>.  An implementation may choose to support these abis, but, given that they are unstable, they are not required to at all.</p>



<a name="229597941"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229597941" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229597941">(Mar 10 2021 at 03:42)</a>:</h4>
<p>It also means that supporting a new ABI for some specialized embedded platform would require going through T-lang, getting them to approve something that doesn't  have a lot of value for the rest of the language or ecosystem, which could be left behind for a good while.</p>



<a name="229598351"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Supported%20ABIs/near/229598351" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Supported.20ABIs.html#229598351">(Mar 10 2021 at 03:46)</a>:</h4>
<p>That's why I mention it would be good to have some way to signify that an ABI is implementation-specific.  Like MSVC uses double leading underscores, something like that.</p>
<p><code>rustc</code> is somewhat special in that it is the primary implementation, it drives the definition of the language. Also, it can do whatever it wants with unstable features.  Unstable things are not in the language reference, and from that perspective they don't exist.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>